num = input().split()
a = float(num[0])
b = float(num[1])
print(a % b)

"""
正确做法见1.3.11-4，这道题出的并不是很好，有一些隐含的格式要求没有说出来。
"""

"""
这道题的存在无疑对浮点运算的困境进行了很好的说明，为什么这么说呢，因为如果你像这样写，连样例都过不了。
样例的输出会是0.46010000000000784。最终测试结果是2分。
之前没有出现这个问题很大程度上是因为大部分题目都限制了结果保留多少位小数，那么最后这一点误差自然就被省略了。
我想这是一个绝佳的时机来讲解两个非常重要但是之前一直没有讲的内容——调试和浮点数误差。
"""

"""
先讲调试。
一个程序的稳健性需要它经得起任何刁钻客户的刁难。有的人可能会想，那我严格限制输入格式，不允许任何不符合格式的操作，不就不会被刁难了吗。
理论上是这样，但是你的程序会有很多个部件，每个部件都可能在特定情况下有让你意想不到的返回。一个简单的格式可能不足以让你规避所有可能的问题。
而且有时候，程序崩溃一次代价太大了，无论如何都要竭力避免造成的损失。我相信如果你玩游戏，在不能保存的长流程快结束的时闪退过都会懂。
或者在处理什么文档的时候还没保存就崩溃了，几小时的辛苦劳动付诸流水。
这些都还是比较轻微的事故。比较严重的事故会造成比”浪费时间“更大得多的损失，比如一个没有保护的仪器控制程序可能把昂贵的器件烧掉。
所以即便在很多时候对稳健性的要求没有那么高，但是完整的测试仍然是必不可少的美德。当然，空口白牙是没用的，大家都多少要一点血的教训才会明白。
以及即便血的教训很多，大概也没有人会真的100%按照安全实验规范操作，即便是接触非常危险的实验也不例外。我完全能理解（我自己也这样）
但是我希望大家至少大概了解这个技能，以备不测。

想必大家都听过经典的程序员酒吧笑话：
一个测试工程师走进一家酒吧，要了一杯啤酒
一个测试工程师走进一家酒吧，要了一杯咖啡
一个测试工程师走进一家酒吧，要了0.7杯啤酒
一个测试工程师走进一家酒吧，要了-1杯啤酒
一个测试工程师走进一家酒吧，要了2^32杯啤酒
一个测试工程师走进一家酒吧，要了一杯洗脚水
一个测试工程师走进一家酒吧，要了一杯蜥蜴
一个测试工程师走进一家酒吧，要了一份asdfQwer@24dg!&*(@
一个测试工程师走进一家酒吧，什么也没要
一个测试工程师走进一家酒吧，又走出去又从窗户进来又从后门出去从下水道钻进来
一个测试工程师走进一家酒吧，又走出去又进来又出去又进来又出去，最后在外面把老板打了一顿
一个测试工程师走进一
一个测试工程师走进一家酒吧，要了一杯烫烫烫的锟斤拷
一个测试工程师走进一家酒吧，要了NaN杯Null
一个测试工程师冲进一家酒吧，要了500T啤酒咖啡洗脚水野猫狼牙棒奶茶
一个测试工程师把酒吧拆了
一个测试工程师化装成老板走进一家酒吧，要了500杯啤酒并且不付钱
一万个测试工程师在酒吧门外呼啸而过
一个测试工程师走进一家酒吧，要了一杯啤酒';DROP TABLE 酒吧
测试工程师们满意地离开了酒吧
然后一名顾客点了一份炒饭，酒吧炸了

解释笑点会显得我很呆，所以我选择不解释。如果你对此不满，我建议你在自己身上找找原因。反省一下你自己难道是那种听不懂的笑话就不会笑的人吗。
我觉得讲到这里就够了。如果经过一番研究你能看懂这个笑话，基本上你已经对要测试什么很有数了。剩下来的就只是在血泪的教训和偷懒的本能中，去寻找属于你自己的平衡。

除此之外，如果我们已经确定了存在问题，我们会希望定位到具体是哪一步出错了，这样才能针对性的进行修改。

首先是如果有错误报告（程序崩溃了）就看错误报告。
错误报告有时候看起来很长，很难看，但其实你并不是每个部分都需要注意。（注意，以下内容仅针对pycharm环境）
首先是Traceback，这个部分显示了发生错误的代码的完整引用途径。他经常会一直追踪到代码的底层，但是你并不需要全都看懂。
每一步引用都会写清楚文件名和行数，你只需要看在你自己的程序中的部分就可以了，剩下的部分就当他不存在，或者等你很熟练了再说。这样你就确定了错误位置
然后是TypeError，这个部分显示的是具体的错误描述。你可以直接看懂它，也可以相信你绝对不是第一个遇到这个问题的幸运儿，向搜索引擎寻求帮助。

如果程序没有崩溃但是结果错了，那就需要先确定到底是在哪一步出了问题。
如何确定呢，最简单的方式就是打印中间结果。在每一个段落之后都打印当前结果如何。这样你就可以确定在最后一个正确的结果到第一个错误结果之间的代码段有问题。
然后通过不断缩短间隔的方式一步步找到到底是哪一行导致了结果错误。然后再去分析这一行为什么会得到这个错误结果而不是你想要的结果。
有一些更高级的方法来实现这一点。比如有的功能可以实现一行一行运行（而不是整个程序仪器运行），或者运行到你标记的某个位置暂停。再配合上追踪变量取值。
这些就需要各位自己去尝试和选择自己更习惯的方法了（以及对于有的环境，这些方法并不是都能用，我说的打印是最通用的）
这说起来简单，其实很容易遇到各种问题。比如简单的情况都没错，只在一个很复杂的情况下出错，但是这个情况复杂到你自己也算不清楚每个中间步骤。
比如问题出在一个非常大的列表里很少数的位置，我就算打印结果，也很难从这么大的表里面找到错误的那几位……
所以debug路漫漫其修远兮，只能仰赖各位的智慧了。
"""

"""
你能在很多地方查到为什么浮点数有误差，他们都会针对某种具体的存储方式告诉你误差在哪。读者如果感兴趣完全可以自己研究
而我想解释一下浮点数特别在哪，凭什么就他幺蛾子特别多：
浮点数和其他类型的本质区别在于，布尔型（只有True，False），整数型，字符型等的特点是他们都是“可列集”，而实数是稠密的（详见数学分析，但不感兴趣不必深究）。
换句话说，对于布尔型，字符型，我们可以轻易列举出全部布尔值和字符，给他们编号，然后进行存储。
例如Bool型，令False=0，True=1。例如字符，我们有ASCII码表，和更大的Unicode码表。总之都可以把集合中所有元素列举出来，然后用集合中的“序”来表示特定元素。
虽然整数不是有限可列的，但是在有限区间内的整数是有限可列的，所以我们会看到很多语言（例如Pascal，Fortran，C，java等等）都是这么干的：
比如我指定一个类型a，这个类型用来存储-2^31~2^31-1范围内的整数，那么此时集合元素总数为2^32，完全可以用32位二进制编码。
如果你想要用更大的整数，就需要其他类型。如果没有其他内置类型，就要自己写。
python智能很多，但本质上也是这个逻辑。只不过python会根据整数大小自动分配空间，但还是走的用可列集合中的序来表示元素的路线。
但是浮点数（或者说实数型）是稠密的，即任意两个实数之间都有无穷多个实数。这件事可以通过构造法轻易证明，这里就不写了。
所以浮点数是唯一不能用序表示的。这就注定了从原理上，都一定会有大量的浮点数没办法在有限的空间内被精确表示。
所以浮点数总是会有各式各样的误差，他们是很多题目莫名其妙做不到满分的罪魁祸首。
"""
